Spring cloud Raft and CAP
拜占庭容错算法（Byzantine Generals Problem）
理想流程
拜占庭容错算法也叫拜占庭将军问题（Byzantine Generals Problem），由莱斯利-兰波特在论文中所提出的分布式对等网络通信容错问题。
假设一组罗马（拜占庭）将军各率领一直军队 共同 围攻一座城市，为简化问题，各种军队的行动策略分别为 进攻与撤退 两种。
每个支部队的将军必须通过投票来达成一致策略（所有军队一起进攻或撤退），因为没支部队位置不同，所以需要 信使 来进行没支部队的互相联系。
此时每支部队将军可以根据自己的投票和其他将军投票的信息来共同知道所决定的行动策略。
实际问题
一致性
假设在这些8个将军中出现了1叛徒，他们不仅可能向较为糟糕的策略进行投票，还可能选择性的传递投票信息（假设4位将军投的进攻，4位将军投的撤退，那么给进攻的将军说他们投的都是进攻，给投撤退的将军说投的都是撤退）。
那么这样各支军队的一直协调即一致性遭到了破坏
可靠性
由于各个将军需要通过 信使进行通讯，那么叛徒将军可能通过伪造的信件以及以其他将军的身份发送假的投票。
即使我们保证了所有将军都可靠的情况下，也不能排除信使被敌人截杀或叛变以及替换等情况，因此很闹保证人员的 可靠性。：
拜占庭容错
假设整套体系都按照理想化正常情况下，将军们仍然可以通过 多数决定战略，而这将会被称之为 拜占庭容错
Raft（Reliable,Replicated,Redundant,And Fault-Tolerant）
概述
Raft 集群（Reaf cluster）中主要分为 领袖（leader）、追随者（follower）、候选人（candidate）。
在一个 Raft 集群中，正常情况下都会有一个领袖，其他都是追随者，领袖会负责所有的外部请求（如果不是领袖机器收到，则请求将会被导到领袖中）。
领袖会有一个固定时间发送消息，即 “心跳（heartbeat）”，让追随者知道领袖还在正常运作。每个追随者都会设计一个计时机制（timeout），当超过一定（通常在 150ms、300ms）时间没有收到领袖的心跳，那么集群将会进入到选举状态。
领导选举
假设领袖机器死机，那么就需要选择新的领袖。此时进入一个新的任期开始选举，成功当选的领袖开始工作，知道他死了出现故障为止，此时将开启新的一轮选举。
选举是 候选人 所发动的，当领导心跳超时的时候追随者就会将自己的任期编号+1，来表示自己参加竞选并投自己一票，并向其他服务器拉票（每台服务器任期只会投一票，固定给最早拉票追随者）
如果候选人收到了其他候选人的拉票，且拉票的任期编号大于自己的任期编号，就会人定位落选并成为追随者，以此认为来拉票的候选人为领袖，如果有候选人收到了过半的宣判就当选为新的领袖
假设在 REST 服务器超时期限过了还没有选出新的领袖时，那么任期将会自动终止，开启新的一场选举。
Raft 的每台服务器超时期限都是随机的，这也降低了同时竞选的几率，也降低了两个竞选人得票不过半的选举失败几率。
这场选举也许不是最为公平的，因为当领袖死机的时候，每个已存储指令必定在服务器中已经写入过半。而选举流程则是会让记录较为完整的候选人来胜选，因为在候选人拉票的时候会透漏自己记录的最新信息。
记录复写
记录复写主要的主角在领袖身上，在 Raft 集群中有一个复写的状态机（State machine）来执行外来的指令，而领袖接受指令来写入记录中。
之后将指令转发给追随者，如果追随者没有反应，领袖会不断的重新发送指令给每个追随者，直到每个追随者将新指令写入记录中为止。
最后领袖收到过半追随者确认写入的信息后，将会将指令视为已存储（committed），追随者发现状态变成已存储，将会在状态机上执行该命令。
当领袖死机的时候，领袖的某些新指令还没有到写入集群当中，因此会造成集群记录处于不一致的问题，因此为解决此问题：
新领袖会担有重返一致性的责任，让每个追随者记录都和他一致。他将每个追随者记录进行比较，找出两者一致的最后一个不一致的指令进行删除，将自己之后的指令拷贝个追随者。
假设追随者司机，那么给他转发的所有指令都会被回应失败，而发送端会持续重新发送。当这台追随者重新加入集群时，就会收到这些指令并重新回应（已经写入的指令不会被重新写入）。
布鲁尔定理（Brewer’s theorem）
概述
布鲁尔定理（Brewer’s theorem）也被称之为CAP定理（CAP theorem），主要指出咋分布式系统中的：
- 一致性（Consistency），执行同一个举动
- 可用性（Availability），每次请求都能获取到正确的响应
- 分区容错性（Partition tolerance），保证服务宕机时其他服务依然可以正常提供服务（系统中任意信息丢失或失败不会影响系统的继续运作）。
三个场景
通过 CAP 定理，我们无法同时满足一致性、可用性、分区容错性这三个特性，因此我们假设：
CP （ 一致性和分区容错性）
CP 即 一致性、分区容错性，牺牲掉了可用性保证了一致性，可能会有几个节点不可用，通常适用与银行系统。
AP（可用性和分区容错性）
AP 是可用性和分区容错性，舍弃掉了一致性，保障服务可用但可能会造成数据的冲突，可适用流量访问大对系统正常提供服务要求较高的系统;
CA（一致性和可用性）
一旦集群中一台服务无法正常提供服务则会造成当前集群完全崩溃，适用与挑战者。
⬅️ Go back